home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1998 April: Mac OS SDK / Dev.CD Apr 98 SDK1.toast / Development Kits (Disc 1) / QuickDraw 3D / RAVE SDK 1.5 MacOS / RaveDemo / ShieldRect.doc < prev    next >
Encoding:
Text File  |  1997-08-14  |  3.3 KB  |  56 lines  |  [TEXT/BOBO]

  1. Description of the ShieldRect
  2.  
  3. What is it?
  4. ShieldRect.lib is a Mac OS PPC only library that provides a mechanism that allows you to register a rectangular region of the screen and be notified BEFORE it is overwritten or changed in any way.
  5.  
  6. Who needs it?
  7. Anyone who is drawing to the screen asynchronously.  This includes hardware drawing systems (such as a hardware 3D card) and software drawing systems such as a multi-processor (multi-threaded) drawing engine.  This document focuses on RAVE engines capable of asynchronous drawing.
  8.  
  9. Who is it NOT for?
  10. This system will probably not be used in Rhapsody.  Rhapsody will most likely have a different scheme for locking screen real estate.  It might be used in the Rhapsody blue box.
  11.  
  12. Why is it needed?
  13. Historically, in the Mac OS drawing to the screen is only allowed during “Event Time”.  That is, when an application returns from a call to WaitNextEvent.  Asynchronous drawing was not allowed.  If you attempted it you would run the risk of overwriting menus and windows and such things.  And if the user changed the screen depth or resolution, you run the risk of drawing into a portion of memory that may be in use by another process.
  14.  
  15. To illustrate the problem lets look at a typical RAVE drawing loop.
  16.  
  17. 1.  App calls QARenderStart()
  18. 2.  App starts submitting triangles to render.
  19. At this point the hardware might start rendering to the screen or to a back buffer.
  20. 3.  App calls QARenderEnd()
  21. 4.  App continues on, and possibly handles user events.
  22. At this point the hardware might still be rendering to the screen.
  23. If the hardware is double buffering, at some point it will have to blit to the screen.
  24.  
  25. The problem arises in step 4.  The user might pull down a menu that covers the portion of the screen that the hardware is rendering to.  The menu will pop down and then promptly be overwritten by the 3D hardware.  The user gets mad and blames the 3D hardware.  This problem is not restricted to the user pulling down a menu.  Here are some more possible problems...
  26.  
  27. user pulls down a menu 
  28. user moves another window over the window being rendered to
  29. user switches to another app
  30. user hides the 3D app
  31. balloon help pops up
  32. dialog or alert box pops up
  33. user changes screen resolution, depth, or position 
  34. screen saver starts
  35. screen goes to sleep
  36. user drags something (an icon) across the window being rendered to
  37. etc...
  38.  
  39. How do I use it?
  40. There are two calls, RegisterShieldRect and UnregisterShieldRect.
  41.  
  42. When you call RegisterShieldRect you pass a Rect in global coords, a function pointer (to a notify function that you provide), and a refCon.
  43.  
  44. When that rectangle is about to be overwriten your notify function will be called.
  45. (Your notify function is also called before the screen depth, resolution or position changes.)
  46. When your notify function is called it gets passed a rectangle indicating the portion of the screen about to be overwriten and the refCon that you passed to RegisterShieldRect.
  47.  
  48. Here is how I see this being used inside a RAVE engine...
  49.  
  50. When the RAVE engine creates a draw context register the rectangle and your notify function with RegisterShieldRect.
  51.  
  52. When your notify function gets called, check if your hardware has any drawing pending for the given draw context.  If so, wait until your hardware is finished drawing, then return.
  53.  
  54. When you delete your draw context, unregister your notify function by calling UnregisterShieldRect.
  55.  
  56.